Mobile communication devices have become popular for business and personal use due to a relatively recent increase in number of services and features that the devices and mobile infrastructures support. Handheld mobile communication devices, sometimes referred to as mobile stations, are essentially portable computers having wireless capability, and come in various forms. These include Personal Digital Assistants (PDAs), cellular phones and smart phones.
More recently, global positioning system (GPS) receivers have been integrated within such mobile communication devices for providing enhanced location-based services (LBS). In operation, a map application within the mobile communication device sends a request to a map server for information relating to a city, restaurant, street address, route, etc. If the device is “location aware”, the request includes the current location of the device. The map server extracts generic map content from a Geographical Information Systems (GIS) map database (e.g. Navtech®, TelAtlas®, etc.) at a specified level of resolution (zoom level). Custom graphics associated with the query, such as highlighted route, pushpin for current position or street address, etc. are post-processed and merged by the server with the generic map content. Relevant screen graphics are then labeled, and the merged map graphic is compressed and delivered to the device for display.
One problem associated with the foregoing technical approach to providing mobile mapping service is that the delivered map graphic (DMG) is in the form of a bit-mapped flat file at a specific zoom level that is not scalable (in either lateral (pan) or vertical (zoom) contexts). After the map graphic has been downloaded to the device, subsequent pan or zoom operations from the device will result in further requests to the server. For example, if a DMG is delivered to the device as a 2 Kbyte map at the lowest level (Level 0) resolution field of view (e.g. 1 meter/pixel), then if the user wishes to zoom in to the next highest level (Level 1) resolution field of view the server is required to deliver four 2 Kbytes maps (e.g. 2 meters/pixel). If the user requests Level 2, then 16 2 Kbyte maps of data must be downloaded to the device, and so on. From the foregoing, it is evident that the inability to provide scaling of bit map data according to conventional techniques gives rise to non-linear growth in the amount of data that is required to be downloaded to the device. Also, by merging the labels with the delivered map graphic any labeling that extends between two DMG files is cut off when one of the files is displayed at the device. Furthermore, shipping label sets with all DMG's only to have them discarded by the device is a waste of bandwidth. A relatively low percentage of map graphics actually get labeled, particularly on the small size screen of a mobile device, thereby causing label clutter/collisions.
It will also be appreciated that the downloading of large amounts of map data according to conventional techniques consumes significant over-the-air (OTA) bandwidth requiring considerable time to complete the download. Furthermore, the storing of such large amounts of map data on the device undermines device capability to cache the data.
Moreover, the DMG often is not geocoded with latitude/longitude association, thereby inhibiting implementation of device features like dynamic updating of current position while the device is in motion, or position resolution of any location tag information on the device, such as personal points of interest, etc. In addition, features on DMG that haven't been labeled cannot be queried.